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REMARKS 

Prior to entry of this paper, Claims 1-45 were pending. In this paper, Claims 1, 14, 19, 
22, 25, 28, 30, 35, 38, and 41 are amended. No new matter is added by way of these amendments. 
No claims are canceled, or added. For the reasons discussed in detail below, Applicants submit that 
the pending claims are patentable over the art of record and respectfully request that the Examiner 
pass this application to issue. 

Claim Objections 

Claim 41 was objected to because it contains a limitation to "information shared" not in the 
claim from which it depends. In response, claim 41 was amended to make it dependent from claim 
40, which includes such limitation. Therefore, the objection is now moot. 

Rejection of Claims 

The Office Action rejected claims 1-7, 9-1 1, 14-15, 19, 22-26, 28, 30-37, and 39-45 
under 35 U.S.C. § 102(b) as being anticipated by U.S. Patent Serial No. 5,187,706 to Frankel et al. 
(herein "Frankel"). Claims 8, 17, 20-21, 29, and 38 were rejected under 35 U.S.C. §103(a) as being 
unpatentable over Frankel, in view of a publication entitled "Computer Organization and 
Architecture," by Null and Lobur (herein "Null"). Claims 12-13, and 18 were rejected under 35 
U.S.C. §103(a) as being unpatentable over Frankel in view of U.S. Patent Publication No. 
2004/0003094 to See (herein "See"). Applicants respectfully traverse these rejections. 

For example, as amended, claim 1 recites a method for mirroring a connection, 
comprising, in part, receiving, exclusively by a first network device a packet from a resource, 
forwarding the packet to another network device, wherein the packet is forwarded exclusively by a 
single forwarding device that is determinable from the first network device or the second network 
device, receiving, exclusively by the first network device, a response packet from the other network 
device, and forwarding, exclusively by the forwarding device, the response packet towards the 
resource. After carefully considering the cited references and the discussion provided in the Office 
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Action, the Applicants submit that the cited references do not disclose or suggest that the packet and 
the response are exclusively sent or received, as recited in at least claim 1 . 

Unlike at least claim 1 , Frankel teaches where broadcasting elements are employed in a 
switching architecture to implement a dual access ring structure. In particular, communications 
traffic from customer location 1 01 is supplied to a broadcasting element 105 over a signal path. A 
broadcasting element replicates the traffic supplied to it and transmits that traffic to at least two 
paths. See Frankel, Col. 1, lines 40-45; Col. 3, lines 10-16; and Figure 1. As disclosed, 
broadcasting element 105 transmits one copy of the customer traffic over link 107 to primary central 
office 102 and another copy over link 108 to backup central office 103. See Frankel, Col 3, lines 
18-21; and Figure 1 . Thus, Frankel fails to teach or suggest that the packet is received exclusively 
by a first network device . 

In addition, Frankel further discloses that broadcasting element 110 duplicates the 
customer traffic supplied from link 1 12 and supplies one copy directly to hub office 104 vial link 
113 and a second copy to hub office 104 indirectly via link 1 14, selection element 1 16 in backup 
central office 103, and link 117. See Frankel, Col 4, lines 41-46; and Figure 1. Thus, the packet is 
received by the other network device is actually received from both the primary central office 102 
a nd the backup central office 103, and not from the first network device or the second network 
device. 

Furthermore, as shown in Figure 2 of Frankel, the selection element 206 in customer 
location 101 receives the customer traffic supplied from link 207 and from link 208 . Thus, Frankel 
fails to suggest or teach that the response packet is forwarded exclusively by the forwarding device 
to towards the resource, as claimed in at least claim 1 . Therefore, because Frankel fails to teach or 
suggest the limitations as recited, at least claim 1 should be allowed to issue. 

Moreover, independent claims 14, 19, 22, 25, 28, 30, and 35 each recite similar, albeit 
different, limitations as claim 1 . For example, claim 14 recites, a method for mirroring a 
connection, comprising, in part, receivin g exclusively, by an active network device, a packet from a 
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resource, forwarding the packet towards another network device, wherein the packet is forwarded 
exclusively by the active network device, forwarding, exclusively b y the active network device, the 
response packet towards the resource. Claim 19, recites a method for mirroring a connection, 
comprising, in part, receiving, exclusively by an active network device, a packet from a resource, 
and forwarding, exclusively by the standby network device, the copy of the response packet towards 
the resource. Claim 22, recites, in part, receiving, exclusively by a standby network device, a 
packet from a resource, and forwarding, exclusively by the active network device, the copy of the 
response packet towards the resource. Claim 25 recites a network device having a processor that is 
configured to perform actions, including, in part, receiving a packet from a resource , wherein the 
packet is sent exclusively towards the network device by the resource, if the network device is a 
forwarding device, exclusively forwarding the packet towards a server, and if the network device is 
the forwarding device, exclusively forwarding the response packet towards the resource. Claim 28, 
similarly, recites a standby network device with a processor that, in part, receives a packet 
exclusively from a resource, and receives a response packet from another resource, wherein the 
response packet is in response to the other resource receiving a copy of the packet exclusively from 
the active server. Claim 30 recites a system, where a first network device performs actions, 
including, in part, receiving a packet from a resource , wherein the packet is sent exclusively towards 
the first network device by the resource. Claim 35, recites an apparatus having a processor to 
perform actions, including, in part, receiving a packet from a resource , wherein the packet is sent by 
the resource exclusively towards the apparatus . Thus, for at least the substantial the same reasons as 
claim 1 , Applicants respectfully submit that, because the cited references do not support a prima 
facie rejection, claims 1, 14, 19, 22, 25, 28, 30, and 35 should be allowed to issue. 

The Office Action further attempts to combine Null with Frankel to reject at least claims 
8, 17, 29, and 38, by suggesting that Null discloses that the TCP/IP system always sends 
acknowledgement packets back to the send of the original packet as a quality control measure. The 
Applicants respectfully submit that broadcast signals, such as used by Frankel do not typically 
employ Acknowledgement packets as suggest by the Office Action. In support of this statement, 
Applicants refer to a paper published in the Proceedings of the 26th IEEE International Conference 
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on Distributed Computing Systems (ICDCS), July 2006, which is enclosed with this response. The 
paper, entitled "High-Throughput Multicast Routing Metrics in Wireless Mesh Networks," by Roy 
Sabyasachi et al, states, "In case of broadcast, there are no acknowledgements and thus a successful 
data transfer only depends on the link quality in the forward direction." See Sabyasachi, page 2, 
Section 2.1, second paragraph. Because Frankel discloses or suggests only using broadcasting in its 
system architecture, Null can not be combined with Frankel as suggest by the Office Action. Thus, 
Frankel combined with Null does not teach acknowledgement packets as claimed by at least claim 
8, 17, 29, and 38. Therefore, because the cited references do not support a prima facie rejection, 
claims 8, 17, 29, and 38 should be allowed to issue. 

In addition, Claims 2-13 depend from claim 1; claims 15-18 depend from 14; claims 20- 
21 depend from claim 19; claims 23-24 depends from claim 22; claims 26-27 depend from claim 
25; claim 29 depends from claim 28; claims 31-34 depend from claim 30; and claims 36-45 depend 
from claim 35. Therefore, for at least the same reasons as their respective independent claims, each 
of the dependent claims is also allowable. Thus, Applicants respectfully submit that Claims 1-45 
are in condition for allowance, and should be allowed to issue. 
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CONCLUSION 

By the foregoing explanations, Applicants believe that this response has responded fully 
to all of the concerns expressed in the Office Action, and believes that it has placed each of the 
pending claims in condition for immediate allowance. Early favorable action in the form of a 
Notice of Allowance is urged. Should any further aspects of the application remain unresolved, the 
Examiner is invited to telephone Applicants' attorney at the number listed below. 



Dated: September 14, 2006 Respectfully submitted, 

By ffa/t^-t?**./ 

Jamie L. j^Jiegand 
/ Registration No.: 52,361 
DARBY & DARBY P.C. 
P.O. Box 5257 

New York, New York 1 01 50-5257 
(206) 262-8900 
(212) 527-7701 (Fax) 
Attorneys/ Agents For Applicants 

Enclosure: 

Proceedings of the 26th IEEE International Conference on Distributed Computing Systems 
(ICDCS), July 2006 
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Abstract 

The stationary nature of nodes in a mesh network has 
shifted the main design goal of routing protocols from main- 
taining connectivity between source and destination nodes 
to finding high-throughput paths between them. In recent 
years, numerous link-quality-based routing metrics have 
been proposed for choosing high-throughput paths for uni- 
cast protocols. In this paper we study routing metrics for 
high-throughput tree or mesh construction in multicast pro- 
tocols. We show that there is a fundamental difference be- 
tween unicast and multicast routing in how data packets are 
transmitted at the link layer, and accordingly there is a dif- 
ference in how the routing metrics for each of these prim- 
itives are designed. We adapt certain routing metrics for 
unicast for high-throughput multicast routing and propose 
news ones not previously used for high-throughput. We then 
study the performance improvement achieved by using dif- 
ferent link-quality-based routing metrics via extensive sim- 
ulation and experiments on a mesh network testbed, using 
ODMRP as a representative multicast protocol. Our testbed 
experiment results show that ODMRP enhanced with link- 
quality routing metrics can achieve up to 1 7.5% throughput 
improvement as compared to the original ODMRP. 



1. Introduction 

Recently, wireless mesh networks have attracted much 
attention. Unlike traditional mobile ad hoc networks 
(MANETs), the routers in mesh networks are static, and 
thus dynamic topology changes are much less of a con- 
cern in such networks. As a consequence, the main de- 
sign goal for routing protocols is shifted from maintaining 
connectivity between source and destination nodes to find- 
ing high-throughput paths between the nodes. Towards this 
goal, more sophisticated routing metrics than the hop-count 
metric have been proposed in the past [7, 1,16, 10, 3, 8]. 
All these metrics have been proposed and evaluated for uni- 
cast routing protocols such as DSDV [24], DSR [15], and 
AODV [25]. 



Multicast is another fundamental routing service in mul- 
tihop mesh networks. It provides an efficient means of sup- 
porting collaborative applications such as video conferenc- 
ing, online games, webcast and distance learning, among a 
group of users. Unlike unicast, all the routing algorithms 
proposed for multicast [27, 13, 17, 30, 1 1, 28, 14, 12, 20] 
use minimum-hop-count as the routing metric and focus on 
scenarios with high mobility. 

In this paper, we study the design of link-quality-based 
routing metrics for high-throughput multicast in mesh net- 
works. Our approach is based on the observation that there 
is a fundamental difference in the way the MAC layer han- 
dles multicast packets as opposed to unicast packets. Typ- 
ically multicast packets are broadcast at the MAC layer as 
opposed to unicast in order to leverage the wireless multi- 
cast advantage (WMA) [4]. Thus directly using the link- 
quality-based metrics proposed for unicast is not appropri- 
ate. 

In this paper, we first study how to adapt the routing met- 
rics developed for unicast for use in multicast in mesh net- 
works. We then study the comparative performance of a set 
of five routing metrics adapted from those for unicast pro- 
tocols, namely, ETT, ETX, PP, Multicast ETX (METX) and 
Success Probability Product (SPP), where METX and SPP 
are adapted from two energy-efficient routing metrics pro- 
posed in [3, 8]. Our study is performed using ODMRP [17], 
a state-of-the-art multicast protocol. 

Our simulation study with a 50-node mesh network 
shows that ODMRP using any of the five metrics, ETT, 
ETX, METX, PP, and SPP, outperforms the original 
ODMRP by significant margins of improvement similar 
to those achieved in unicast routing using high-throughput 
routing metrics [9]. In particular, on average, ODMRP us- 
ing SPP or PP achieves 18% higher throughput than the 
original ODMRP. Our experiments on an eight-node testbed 
show that on average, ODMRP using SPP and PP achieve 
14% and 17% higher throughput over ODMRP, respec- 
tively. To the best of our knowledge, this is the first study 
on high-throughput routing metrics for multicast in wireless 
mesh networks. 
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The rest of the paper is organized as follows. Section 2 
discusses the fundamental difference between multicast and 
unicast modes of communication in multihop wireless net- 
works and describes how to accordingly modify the exist- 
ing unicast routing metrics for multicast routing. Section 3 
describes the changes made to ODMRP in order to incorpo- 
rate the routing metrics. Section 4 presents simulation re- 
sults and Section 5 presents experimental results on a mesh 
network testbed. Finally, Section 6 concludes the paper. 

2. Routing metrics for multicast protocols 

In this section, we first discuss the differences in the way 
the link layer handles data packets in unicast and multicast 
and the implications on the design of high-throughput link- 
quality-based routing metrics. We then present how to adapt 
different link-quality metrics originally designed for unicast 
routing for use in multicast routing. 

2.1. Differences between link- layer unicast 
and multicast 

Data packets are handled differently at the link layer in 
unicast routing and multicast routing, and the difference 
has direct implications on the design of high-throughput 
link-quality metrics. Most multicast protocols (for exam- 
ple, [17, 5, 27, 13, 29]) use link-layer broadcast to lever- 
age WMA. WMA improves the reliability of data transfer 
and hence increases efficiency. In contrast, data packets in 
unicast are handled using link-layer unicast. The most com- 
monly used link/MAC layer protocol in wireless ad hoc net- 
works is the IEEE 802.1 1 MAC layer protocol. The 802.1 1 
MAC layer unicast involves an RTS/CTS exchange before 
sending data. The RTS/CTS exchange avoids the hidden 
terminal problem by reserving the channel via a virtual car- 
rier sense mechanism. This reduces the probability of col- 
lision during data transfer. Further, data transmission is ac- 
knowledged by the receiver. If an acknowledgment is not 
received, the MAC layer reattempts the data transmission 
for a number of times. In contrast, the 802.1 1 MAC layer 
broadcast does not involve any RTS/CTS exchange. This 
effectively increases the probability of collisions. Further- 
more, it does not involve any link layer acknowledgment or 
data retransmission. This further reduces the reliability of 
broadcast transmission. 

The abovementioned differences in unicast and broad- 
cast data transmissions have two major implications on the 
design of link-quality metrics. First, the link quality that 
matters is bidirectional in unicast, but unidirectional in mul- 
ticast. In case of unicast, a successful data transfer consists 
of a successful transfer of a packet from a sender to a re- 
ceiver followed by a successful transfer of an acknowledg- 
ment back, in addition to an exchange of RTS/CTS between 
the two nodes. Hence, the overall quality of a link depends 



on the link characteristics in both the forward and reverse 
direction. In case of broadcast, there are no acknowledg- 
ments and thus a successful data transfer only depends on 
the link quality in the forward direction. Hence, in case of 
broadcast, the link quality in the reverse direction should not 
be considered in the link-quality metric as it may distort the 
metric value of a link. Moreover, since in broadcast there 
are no retransmissions, a data packet has only one chance to 
properly travel from one node to another. This implies that 
unlike unicast, for loss-rate-based link-quality metrics such 
as ETX, simply adding the metric values of the individual 
links along a path does not properly reflect the quality of 
the entire path. Instead, a product of the metric values of 
the individual links better reflects the quality of the path. 

2.2. Adapting unicast link-quality metrics 
for multicast 

The above differences between unicast and multicast 
suggest that the link-quality metrics designed for unicast 
can not be directly used in multicast protocols. In the fol- 
lowing, we describe how to adapt these link-quality metrics 
for use in multicast protocols. All metrics involve sending 
periodic probes from a node to each of its neighbors. The 
metric of each link is calculated by the receiver which adds 
it to the path metric as query packets flow through, i.e., dur- 
ing multicast tree construction. 

PP We adapt unicast PP [16, 9] for multicast by broad- 
casting probe packets instead of unicasting them to each 
neighbor node. A pair of probe packets are sent every 10 
seconds. The delay for a link is calculated as an Expo- 
nentially Weighted Moving Average (EWMA). We assign 
a weight of 90% to the accumulated average and 1 0% to 
the current one. Another modification we introduced is that 
in case either the large or the small packet is lost, a 20% 
penalty is imposed. The value of the metric for a path is the 
sum of the PP values of the individual links. 
ETX We adapt unicast ETX [7] for multicast by not con- 
sidering reverse path link quality. A probe packet is sent 
every five seconds, and ETX is now defined as ETX = j-, 
where d/ is the loss rate of the link in the forward direction. 
The value of the metric for a path is the sum of the ETX 
values of the individual links. 

ETT Since we do not assume multiple channels when 
comparing different metrics in this paper, we adapt 
ETT [10] instead of WCETT for use in multicast. The value 
of the metric for a path is the sum of the ETT values of the 
individual links. Probing is performed in the same way as in 
PP. ETT of a link is composed of information about the loss 
rate and the bandwidth of a link. In the adapted ETT, the 
receiver uses the small packets received to calculate ETX. 
The bandwidth of each link is estimated by dividing the size 
of the big packet by the inter-arrival time between the small 
and the large packets. 
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METX In [8], the authors propose routing metrics to min- 
imize the total transmission energy. Under the assumption 
of an unreliable link layer, they propose an energy-efficient 
routing metric for a path 

C{s,d) = - — [C(s,u) + W(u,d)\ (1) 

1 - Pern 

where C(s, d) is the expected energy-cost of transmission 
from a source s to destination d, I is the link between u and 
d in the path, p errl is the error rate of that link, and W (u, d) 
is the transmission energy required between nodes u and 
d. We modify the metric given by Equation (1) to a new 
metric, Multicast ETX (METX). Since mesh networks are 
not energy constrained, we set W(u, d) in Equation (1) to 
1 . Such a transformation gives us the total expected number 
of transmissions needed by all the nodes along a path from 
a source to a destination in order to guarantee successful 
reception of at least one packet at the receiver. METX can 
be expressed as 

MCTX = g n M i'-,w,) < 2 > 

where i denotes the ith link along a path from a source to a 
destination comprising n links. 

SPP In [3], the authors propose an energy-efficient rout- 
ing metric for a path 

EER approx = ^j^f* (3) 
n" = iU - Pern) 

where i denotes the i th link, E t is the energy required to 
transmit over that link. We modified Equation (3) to pro- 
pose the Success Probability Product (SPP) metric. The 
value of SPP for a path consisting of n links is given by 
SPP = niLi d fi< where d fi = 1 ~ Perri- Note that if we 
set Ei in Equation (3) to 1 , the resulting value is n times 
the value of 1/SPP. Note that SPP gives the the probability 
for the destination node to receive a packet properly over 
a path with link-layer broadcast, and hence 1/SPP reflects 
the expected number of transmissions at the source itself. 
The routing algorithm selects the path with the maximum 
SPP (minimum 1/SPP). Note that unlike all other metrics 
described in this paper, a high value of SPP for a path im- 
plies a good (high-throughput) path and a low value implies 
a bad (low-throughput) path. 

Figure 1 gives an example showing why SPP is superior 
to a metric such as METX that tries to minimize the total 
number of transmissions. 

3. Methodology 

To evaluate the throughput improvement under the 
various link-quality metrics for multicast, we chose 




Figure 1. SPP can choose higher-throughput paths than 
METX by minimizing the expected number of packet trans- 
missions at the source. The numbers over the links denote 
the forwarding probability (d fi = 1 - p erTi ) of each link. 



ODMRP [17], a state-of-the-art protocol, as a representative 
multicast protocol for wireless multihop networks. Note 
that the various link-quality metrics can easily be incorpo- 
rated into any other routing protocol and we believe that 
the findings would not change drastically if the underlying 
multicast protocol is changed. In this section we describe 
the distributed implementation of the link-quality metrics 
over ODMRP. 

3.1. Incorporating link-quality metrics 

To incorporate the new link-quality metrics into 
ODMRP, we modified ODMRP as follows. Each node 
maintains a NEIGHBOR TABLE that records the costs of 
the links from its neighbors to itself. The costs are de- 
fined according to the link-quality metric being used, and 
are periodically updated. In the modified ODMRP each 
node looks up the Neighbor Table for the cost of the link 
from which it received the Join Query and using this link 
cost, it updates the cost in the Join Query packet before 
rebroadcasting it. Finally, when the Join Query reaches 
a group member, it contains the total cost of the path trav- 
eled. Instead of sending back a JOIN REPLY immediately 
after getting the first JOIN Query, a group member waits 
for a period of 6 seconds. During this period, it accumulates 
several duplicate Join Query packets and stores the best 
among them, based on the cost of the path traveled by each 
Join Query. After the period of 5 seconds expires, the 
member constructs the JOIN TABLE using the stored JOIN 
Query, i.e., the best among all Join Query packets re- 
ceived during the 5 period, and broadcasts the JOIN REPLY 
to its neighbors. Note that the S period effectively controls 
the diversity of the paths that a member gets to choose from. 
This implementation is similar to the version of ODMRP 
that uses mobility prediction [18]. 

To achieve more diversity in the paths received by each 
group member, each intermediate node is allowed to for- 
ward duplicate JOIN Query packets similarly as in [22]. 
To limit the overhead of queries, we impose two restric- 
tions. First, a duplicate query is forwarded only if the cost 
of the path it has traveled is less than that of the minimum 
cost query received till then. Second, each node sets a timer 
for a period of a < 6 seconds when it receives the first JOIN 
Query with a particular sequence number. Each node for- 
wards duplicate queries only until the timer of a seconds ex- 
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pires. It is important to choose a carefully as a very small 
value will lead to minimal path diversity, and a very high 
value may lead to a high query processing overhead. 

In the rest of the paper, we will denote the orig- 
inal version of ODMRP as ODMRP, and the ver- 
sions that incorporate PP, ETX, METX, ETT, and 
SPP as ODMRP.PP, ODMRP .ETX, ODMRP _METX, 
ODMRP-ETT, and ODMRP .SPP, respectively. 

4. Simulation Results 

4.1. Simulation setup 

We used the Glomosim [31] simulator in our simulation 
study. We simulated a network of 50 static nodes placed 
randomly in a 1000m x 1000m area. We used two multi- 
cast groups with ten members each. The sources sent CBR 
traffic, consisting of 512-byte packets sent at a rate of 20 
packets/second 1 . The radio propagation range was 250m 
and the channel capacity was 2 Mbps (the data rate used for 
broadcast in 802.1 1 MAC protocol). The simulation dura- 
tion was 400 seconds. The TwoRay propagation model was 
used. In our simulations we used 8 equal to 30 msec and a 
equal to 20 msec. In additional simulations, we found us- 
ing much higher values of a and 5 can yield an additional 
3-4% throughput improvement. However, the optimal val- 
ues of a and S are functions of the network size, and au- 
tomatically determining such values is part of our future 
work. We used the Rayleigh fading model in our simula- 
tions, as it is appropriate for environments with many large 
reflectors, e.g. walls, trees, and buildings, where the sender 
and the receiver are not in Line-of-Sight of each other. We 
envision that such environments will be common for mesh 
networks. We simulated each protocol on 10 different ran- 
domly generated topologies and the results for the average 
over all topologies are presented. 

4.2. Results for Single Source per Group 

In this section, we present the performance results of the 
various versions of ODMRP with single source per group. 
Unless otherwise stated, we show the results of ODMRP 
using various link-quality metrics normalized with respect 
to that of the original ODMRP. 

4.2.1. Throughput 

Figure 2, column "Throughput-simulations" shows the 
relative throughput results for the different ODMRP 
versions. In particular, ODMRP has the lowest through- 
put, ODMRP.SPP and ODMRP_PP have the highest 
throughput, and on average, ODMRP -SPP, ODMRP.PP, 

'Although the source sending rate is only 80 Kbps, the actual load on 
the network is much higher as taking the node density into account, the 
total traffi c load within a transmission range is on average 600 Kbps. 
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Figure 2. The relative performance of the different rout- 
ing metrics in terms of throughput and delay normalized 
with respect to ODMRP. 

ODMRPJvlETX, ODMRP.ETX and ODMRP _ETT 
achieve about 18%, 18%, 16%, 14.5%, and 13.5% higher 
throughputs than ODMRP, respectively. Note that we 
also did simulations under lower load and found sim- 
ilar qualitative results, but are not shown due to space 
limitation. 

ODMRP performs poorly because of fading. Fading is 
defined as a random change in the attenuation of a commu- 
nication channel. Fading can directly affect the link quality. 
Every receiver has a receive threshold, which defines the 
signal strength below which the receiver cannot receive a 
signal properly. With fading, the signal strength may fluc- 
tuate up and down. This can cause a packet that would have 
been dropped to be received and vice versa. In particular, 
the quality of long links is adversely affected. 

The path from a source to a receiver, chosen by ODMRP, 
depends on the path taken by the Join Query that reaches 
the receiver first, which is, in most cases (except when the 
Join Query along the shortest paths is lost), the shortest- 
hop path from a source to a destination which typically con- 
sists of long links. As fading causes long links to be lossy, 
ODMRP tends to choose low-throughput paths. In contrast, 
all other ODMRP versions take into account the link qual- 
ity in terms of loss rate, delay, or available bandwidth while 
picking paths, and therefore, they tend to pick paths with 
shorter links which achieve higher throughput. 

Figure 2 also shows that ODMRP -ETX performs bet- 
ter than ODMRP-ETT although both of them take into ac- 
count the loss characteristics of a link in a similar way 
(ETT uses ETX to estimate the loss rate). This is due 
to ODMRP-ETT 's high overhead of probe packets (Sec- 
tion 4.2.2), which was confirmed by running ODMRP.ETX 
with ODMRP.ETT's overhead and getting similar results 
for both of them. 

Figure 2 also shows that ODMRP _PP achieves higher 
throughput than every other version except ODMRP .SPP. 
This result is interesting because intuitively one would ex- 
pect ODMRP.PP to perform only as well as ODMRP-ETT, 
since they have the same (large) overhead and both of them 
take loss as well as delay into account (ETT incorporates 
delay information via bandwidth). The reason for such a 




Figure 3. SPP can choose longer and higher-throughput 
paths than ETX by avoiding a path containing even a single 
lossy link. The numbers over the links denote the forward- 
ing probability of each link. 



difference between PP and ETT is the way in which a packet 
loss is penalized. PP puts a 20% penalty on the EWMA of 
the delay values. If a link is very lossy, the old EWMA 
dominates the component from the new measurement, the 
penalty is effectively incurred repeatedly on the EWMA, 
and at high loss rates, the link cost grows as an exponential 
function of time. Such an exponential growth due to one 
bad link can cause the path cost to blow up. This property 
makes PP penalize bad links heavily and thus more likely to 
avoid them. 

Figure 2 also shows that among all the protocol ver- 
sions, ODMRP_SPP along with ODMRP _PP achieves the 
highest throughput. On average, ODMRP J3PP outperforms 
ODMRP _METX, ODMRP _ETX and ODMRP _ETT by 2%, 
3.5% and 4.5%, respectively. With SPP being a product 
of probabilities, ODMRP _SPP is more effective in avoiding 
paths containing high-loss links than the other protocols as 
one such link decreases the metric value of the entire path 
multiplicatively. It is for this reason that ODMRP .SPP out- 
performs ODMRP .ETX and ODMRP _ETT, both of which 
take the sum of the link-quality metrics of the individ- 
ual links constituting a path. Figure 3 illustrates how 
ODMRP _SPP is capable of choosing better throughput 
paths than ODMRP _ETX using an example network. 

Finally, ODMRP -METX outperforms ODMRP _ETT 
and ODMRP -ETX because it is more aggressive in avoid- 
ing lossy links and unlike ETX and ETT, METX takes into 
account the unreliability of the link layer while calculating 
the expected number of transmissions. But, it is less ag- 
gressive than ODMRP -PP and ODMRP -SPP and hence the 
difference in performance. 

In summary, ODMRP -SPP and ODMRP _PP achieve 
higher throughputs by heavily penalizing lossy links and 
thereby avoiding them. ODMRP .ETX and ODMRP .ETT 
also penalize lossy links but they are less aggressive in do- 
ing so and therefore not as effective. ODMRP _METX is 
a hybrid of ETX and SPP and hence its performance lies 
between those two. ODMRP does not consider any link 
characteristics and tends to choose short paths consisting of 
long links that are lossy, hence it performs poorly in terms 
of throughput. 



Table 1 . Comparative percentage overhead for the differ- 
ent routing metrics. 

I Metric I ETT I ETX I METX I PP I SPP~| 
| % Overhead | 3.03 | 0.66 | 0.61 | 2.54 | 0.sT~j 

4.2.2. Probing overhead 

In this section, we compare the probing overhead of vari- 
ous protocol versions that use link-quality metrics. Table 
1 shows the percentage of bytes from probe packets out of 
the total number of data bytes received. We observe that 
ODMRP .PP and ODMRP .ETT have about 3% higher prob- 
ing overhead than ODMRP _ETX, ODMRP JvlETX and 
ODMRP -SPP. This has two implications. First, although 
ODMRP .ETX and ODMRP .ETT have similar ways of es- 
timating the link loss rates, the former will have higher 
throughput values. Second, the overhead affects the relative 
end-to-end delay which will be discussed in Section 4.2.3. 

There is a tradeoff between the probing overhead and 
the throughput achieved. Higher probing rate implies more 
recent information about the network condition and hence 
more informed decision making. However, probing itself 
can be a source of interference to the data traffic and cause 
loss in throughput. Thus choosing the correct probing rate is 
crucial. To underline the importance of choosing the prob- 
ing rate carefully, in Figure 2 the column "Throughput-high 
overhead" shows the throughput gains for all versions us- 
ing link-quality metrics when the probing rate is increased 
by 5 times. Compared to Figure 2, column "Throughput- 
simulations", we see that the throughputs of all the metrics 
drop by about 2%. We also conducted simulations with a 
probing rate 10 times lower (the results are not shown due 
to page limitation), and found the throughput gains are im- 
proved by around 3%. These results suggest that the prob- 
ing rate indeed affects the throughput gains achieved. These 
results also indicate that high overhead metrics such as PP 
and ETT are more sensitive to the probing rate than ETX, 
METX, or SPP, as these metrics incur much higher probing 
overhead than the others. 

4.2.3. Delay 

We also measured the normalized average end-to-end de- 
lay for ODMRP under each of the metrics with re- 
spect to ODMRP. The results, shown in Figure 2, col- 
umn "Delay", show that in most cases, ODMRP -SPP and 
ODMRP -ETX achieve lower end-to-end delays than the 
rest of the ODMRP versions. This is because ODMRP -SPP 
and ODMRP .ETX have very low probing overhead which 
reduces the delay at each hop, because each node faces less 
contention for the channel. This is also the reason why 
ODMRP -ETX and ODMRP -SPP achieve lower delay than 
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ODMRP_ETT despite that ETT takes into account delay 
(the available bandwidth incorporates delay information). 
Due to similar reasons, ODMRP _PP is also outperformed 
by ODMRP.ETX and ODMRP.SPP, in terms of delay. Be- 
sides lower probing overhead, smaller end-to-end delay is 
another advantage that ODMRP.SPP has over ODMRP _PP. 

4.3. Results for Multiple Sources per Group 

Since ODMRP creates forwarding group members per 
group and not per source 2 , it builds a more redundant mesh- 
structure when there are multiple sources per group than 
when there is a single source per group. This increased 
redundancy of data delivery paths compensates the orig- 
inal ODMRP 's inability to choose high-throughput paths 
and reduces the throughput improvement from using high- 
throughput routing metrics. Our simulation results show 
that the relative throughput gain is reduced by around 10- 
1 5% for the different link metrics (The details are omit- 
ted due to space limitation and can be found in [26].) 
However, this does not undermine the importance of high- 
throughput metrics for several reasons. First, such met- 
rics continue to be effective in multicast protocols that are 
tree-based such as MAODV [27]. Second, when the net- 
work is relatively large and the number of sources per 
group is not high enough to create enough path redundancy, 
high-throughput metrics can still significantly improve the 
throughput. Third, higher path redundancy may lead to 
more unnecessary data traffic in the network. 

5. Testbed experiments 

To validate the effectiveness of the high-throughput 
link-quality metrics for multicast observed in our simula- 
tion study, we performed experiments on an 8-node wire- 
less mesh network testbed. Specifically, we implemented 
ODMRP using all the different routing metrics and exper- 
imentally compared them to the original ODMRP on this 
testbed. 

5.1. Setup 

Our testbed [21] consists of 8 wireless mesh routers 
(small form factor PCs with Intel Pentium 4 processors) 
spread out over a typical academic building floor of length 
240 feet and width 86 feet, approximately. Each mesh 
router is equipped with a single Atheros 5212 802. 1 lb wire- 
less card. Each radio is attached to a 2dBi rubber duck om- 
nidirectional antenna with a low loss pigtail to provide flex- 
ibility in antenna placement. Each mesh router runs Linux 
kernel 2.4.20-8 and the open-source hostap drivers are used 

2 A node that is made a forwarder as consequence of a JOIN Query 
sent by one source may also act as a forwarder for the packets from some 
other source of the same group. 



to enable the wireless cards. The IP addresses are statically 
assigned. The wireless cards we use can support a wide 
range of power settings (0 - 1 8dbm). We used them in their 
default operational mode. 

The nodes are statically placed in the offices on the sec- 
ond floor of an office building on the Purdue campus, as 
shown in Figure 4. The testbed deployment environment 
is not wireless friendly, having floor-to-ceiling office walls 
instead of cubicles, as well as some laboratories with struc- 
tures that limit the propagation of wireless signals. Apart 
from structural impediments, interference exists in our de- 
ployment from other 802.1 lb networks. 

5.2. Protocol Implementation 

We implemented our own version of the original 
ODMRP and enhanced it with the the different link-quality 
metrics. We were unable to obtain the only known imple- 
mentation of ODMRP [2]. In addition, the previous im- 
plementation has been developed for a much older Linux 
kernel (v2.0) and would have incurred portability issues in 
our testbed. Different from the implementation in [2], we 
chose to implement ODMRP as an application-layer dae- 
mon odmrpd for ease of debugging, deployment and use. 
Similar to our approach, many unicast protocols are cur- 
rently being developed or have been developed [ 19, 6, 23] as 
user-level daemons with loadable kernel modules for packet 
capturing and routing. 

odmrpd captures IP packets with multicast addresses us- 
ing the Linux NetFilter mechanism and uses these addresses 
as group IDs. It then uses UDP broadcast to propagate each 
Join Query packet throughout the network. Join Re- 
ply packets are similarly propagated using UDP broadcast. 
Once the forwarding group for a multicast group is formed, 
each data packet for that multicast group is propagated via 
the corresponding forwarding group by the odmrpd at each 
hop. Each node that wishes to receive packets for a multi- 
cast group opens a socket to receive data on the multicast 
address for that multicast group. The odmrpd at each node 
can deliver data packets for all multicast addresses to the 
applications running on the node. 

5.3. Results 

Figure 4 shows the links with connectivities in our 
testbed. Note that in this case, the link quality and the 
link distances do not directly correspond. The link quality 
mainly depends on the obstacles present, such as walls and 
metallic objects. In order to get an estimate of the link qual- 
ity, we transfered a series of ping messages between each 
pair of nodes. The number of packets lost during the ping 
exchange gave us an idea of the quality of the link. Based on 
the results obtained using ping messages, we qualitatively 
classify each of the links as low-loss or lossy. The dashed 
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Figure 4. The fbor map of our eight-node mesh network testbed deployed in an offi ce building. 



lines show the links that are lossy and the solid lines show 
the links that have low or almost no loss. The pairs of nodes 
with no lines between them cannot communicate with each 
other. We do not show any numerical values of loss rates of 
the links because these values change fairly quickly. 

We performed our multicast experiments with 2 multi- 
cast groups, each having 1 source and 2 receivers. The first 
multicast group had node 2 as the source and nodes 3 and 
5 as the receivers, and the second group had node 4 as the 
source and nodes 1 and 7 as the receivers. The rest of the 
nodes acted only as forwarding nodes. Each source sent 
CBR traffic at a rate of 20 packets/second, each of size 512 
bytes. The experiments were run for 400 seconds. The same 
experiment was run five times to make the results resilient 
to random changes in the environment. 

Figure 2, column "Throughput-testbed" shows the 
throughput obtained by all the metrics normalized 
with respect to the throughput obtained by the original 
ODMRP, averaged over all receivers. ODMRP -SPP, 
ODMRP_METX, ODMRP.ETX, and ODMRP _ETT 
achieve gains of around 14%, 7.5%, 8% and 7%, re- 
spectively. Somewhat surprisingly, ODMRP -PP achieves 
on average a 17.5% gain, 3.5% higher than that of 
ODMRP.SPP. Such a gain is not seen in simulations 
because of the following reason. Under high loss-rates, 
PP has the property of causing the cost of a path to blow 
up exponentially. But under moderately low loss rates, the 
cost stabilizes to a constant value. In the testbed scenario, 
all the dashed links have loss rates in the range of 40% to 
60%, which are higher than those seen in the simulations. 
Consequently, PP causes the cost of paths using such links 
to go up very fast and once the cost explodes, any path 
containing such links is never chosen in the future because 
PP uses a long history based on EWMA. On the other hand, 
SPP, ETX, ETT and METX penalize such links during 



some of the route request phases. However, when such 
links become relatively less lossy due to random temporal 
variations, they are chosen again under these metrics 
because such metrics have a small history window. 

Independent of the above observations, the rea- 
son that ODMRP .PP, ODMRP-SPP, ODMRP -METX, 
ODMRP .ETX and ODMRP.ETT achieve throughput gains 
over ODMRP (though with varying amounts) can be ex- 
plained by the difference between the multicast trees con- 
structed by ODMRP and ODMRP using the various rout- 
ing metrics. We use ODMRP -PP as an example for further 
illustration. Figure 5 shows the paths taken by ODMRP 
versus those by ODMRP -PP. The solid and dashed arrows 
denote the heavily used links for ODMRP JP and ODMRP, 
respectively. For the sake of clarity, we removed the floor 
map from the background and kept only the node positions 
in the figure. First we discuss about the paths to receivers 5 
and 7. ODMRP chooses the one-hop path from node 2 to 5 
which is lossy (see Figure 4). Similarly, node 4 chooses a 
one-hop path to 7 which is lossy. In contrast, ODMRP -PP 
chooses relatively longer but higher-throughput paths. For 
example, node 2 reaches 5 along a two-hop path, via 10. 
Similarly, node 4 reaches 7 along a two-hop path, via 9. 
For receivers 1 and 3, sources 2 and 4 have more than one 
paths. Node 2 can reach 3 via 7 or 1 ; similarly, node 4 can 
reach 1 via 10 and 2, or 7 and 2, or 7 and 3, or 9 and 3. 
But ODMRP can not distinguish between the various alter- 
native paths and often chooses the lossy path containing the 
link between 3 and 1, or 4 and 7, or 9 and 3. ODMRP _PP is 
again able to figure out the lossy links and avoid them. 

6. Conclusions and Future Work 

In this paper, we have studied various link-quality rout- 
ing metrics for high-throughput multicast in mesh networks. 
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Figure 5. The trees constructed by ODMRP and 
ODMRP.SPP. The dashed circles denote nodes that do not 
belong to any group. The solid and concentric circles de- 
note nodes of two different multicast groups. 

We first discussed the fundamental difference between uni- 
cast and multicast routing in how data packets are transmit- 
ted at the link layer, and then showed how to adapt unicast 
routing metrics for use in multicast. We studied the per- 
formance of different metrics via extensive simulations and 
experiments on a mesh network testbed, using ODMRP as 
a representative multicast protocol. Our simulation studies 
have shown that ODMRP equipped with any of the link- 
quality-based routing metrics can achieve higher throughput 
than the original ODMRP. We also found that heavily penal- 
izing lossy links is an effective way to avoid low-throughput 
paths and SPP and PP achieve the highest throughput per- 
formance because of their aggressive manner of penalizing 
lossy links. Moreover, SPP has much less overhead than PP, 
which reduces the end-to-end delay. We have also observed 
a tradeoff between throughput gains achieved and the prob- 
ing overhead incurred, i.e., higher probing rate gives more 
recent information about the network but also causes inter- 
ference for data packets. Finally, our experimental results 
on an eight-node mesh network testbed validate the results 
obtained in the simulation study. 

In our future work, we plan to investigate more about 
the optimal probing rate, and to extend the high-throughput 
link-quality metrics studied in this paper for multicast rout- 
ing in multi-radio/multi-channel mesh networks. We also 
plan to significantly expand our testbed which will give 
more diversity in the network topologies. 
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